Add codebase risk assessment reports#31
Conversation
… integration - Updated Dashboard component to use orchestrator for SOS activation and deactivation. - Introduced SOSRuntimeBootstrapper for handling app state recovery and deep-link triggers. - Added new orchestrator functions for managing SOS pending intents and cooldowns. - Integrated power button detection for triggering SOS via native module on Android. - Enhanced background location tracking with updated distance interval settings. - Created new files for SOS orchestrator and power button handling. - Added comprehensive SOS emergency test checklist for validation.
…d smooth transitions
- Implemented CloudinaryUtils class for handling image uploads and deletions. - Added methods for uploading images from data URIs and file paths. - Included signature generation for secure API requests. - Created SOSProfile component as a placeholder in the frontend.
…feLine into Abhishek
- Updated error.utils.ts to improve type definitions for error handling. - Modified tsconfig.json to use ES2020 for better compatibility. - Added Backend Architecture and Integration Guide for comprehensive documentation. - Implemented location stabilizer utility to filter and smooth GPS updates, reducing noise and improving accuracy. - Refactored User Dashboard and location task to integrate location stabilization, ensuring consistent updates. - Documented changes in frontend location accuracy change log for clarity and future reference.
- Updated SOCKET_API.md to reflect new location update frequency and filtering. - Removed outdated frontend location accuracy change log; created a new log with detailed changes. - Revised implementation plan to include updated location handling and user experience improvements. - Added new utility for location stabilization to reduce noise and improve accuracy. - Reworked Dashboard component to manage location updates more effectively, preventing duplicate emissions. - Implemented background task improvements for consistent location tracking. - Documented changes in frontend location accuracy and filtering behavior.
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly expands the LifeLine emergency response system by integrating advanced AI triage capabilities with the SOS lifecycle, introducing a flexible payment and verification system for helper services, and dramatically improving the reliability and accuracy of real-time location tracking. It also includes a substantial amount of new documentation, providing detailed architectural insights, implementation plans, and comprehensive risk assessments for the entire codebase. These changes aim to create a more robust, intelligent, and user-friendly emergency platform. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a substantial number of features and documentation, including codebase risk assessments, a full payment and OTP verification flow for emergencies, SOS profile access for helpers, and significant enhancements to location tracking on both frontend and backend. While the additions are extensive, I've identified a critical security vulnerability related to serving uploaded files publicly. I've also noted opportunities for code deduplication and schema simplification to improve maintainability. Overall, this is a major step forward, but the security issue should be addressed before merging.
Note: Security Review did not run due to the size of the PR.
| app.use(express.json()); | ||
| app.use(express.urlencoded({ extended: true })); | ||
| app.use(cookieParser()); | ||
| app.use('/uploads', express.static(path.join(__dirname, 'uploads'))); |
There was a problem hiding this comment.
Serving the uploads directory directly via express.static exposes all uploaded files, including potentially sensitive user profile pictures (PII), to the public without any authentication. Anyone with a direct link could access these files.
For better security, all sensitive files should be served through an authenticated route that verifies the user's permission to access the file. Alternatively, using a cloud storage service that supports signed URLs with a short expiration time (like the newly added Cloudinary integration) would be a more robust solution.
There was a problem hiding this comment.
| const parseNearbyQueryParams = (query = {}) => { | ||
| const latitudeRaw = query.latitude ?? query.lat; | ||
| const longitudeRaw = query.longitude ?? query.lng; | ||
|
|
||
| if (latitudeRaw === undefined || longitudeRaw === undefined) { | ||
| throw new Error('Latitude and longitude are required.'); | ||
| } | ||
|
|
||
| const latitude = Number(latitudeRaw); | ||
| const longitude = Number(longitudeRaw); | ||
|
|
||
| if (!Number.isFinite(latitude) || !Number.isFinite(longitude)) { | ||
| throw new Error('Invalid coordinates provided.'); | ||
| } | ||
|
|
||
| const radiusKmRaw = | ||
| query.radiusKm !== undefined | ||
| ? Number(query.radiusKm) | ||
| : query.radiusMeters !== undefined | ||
| ? Number(query.radiusMeters) / 1000 | ||
| : query.maxDistance !== undefined | ||
| ? Number(query.maxDistance) / 1000 | ||
| : query.radius !== undefined | ||
| ? Number(query.radius) | ||
| : 10; | ||
|
|
||
| const radiusUnit = String(query.radiusUnit || '').toLowerCase(); | ||
| let radiusKm = radiusKmRaw; | ||
|
|
||
| if (radiusUnit === 'm' || radiusUnit === 'meter' || radiusUnit === 'meters') { | ||
| radiusKm = radiusKmRaw / 1000; | ||
| } else if ( | ||
| radiusUnit === 'km' || | ||
| radiusUnit === 'kilometer' || | ||
| radiusUnit === 'kilometers' | ||
| ) { | ||
| radiusKm = radiusKmRaw; | ||
| } else if (query.radius !== undefined && radiusKmRaw > 1000) { | ||
| // Backward compatibility: some clients pass radius in meters. | ||
| radiusKm = radiusKmRaw / 1000; | ||
| } | ||
|
|
||
| if (!Number.isFinite(radiusKm) || radiusKm <= 0) { | ||
| radiusKm = 10; | ||
| } | ||
|
|
||
| return { | ||
| center: { lat: latitude, lng: longitude }, | ||
| radiusKm, | ||
| }; | ||
| }; |
There was a problem hiding this comment.
The parseNearbyQueryParams function is duplicated from LifeLine-Backend/src/api/Location/Location.controller.mjs. This duplication makes the code harder to maintain, as any changes or bug fixes would need to be applied in both places.
To improve maintainability and adhere to the DRY (Don't Repeat Yourself) principle, this function should be extracted into a shared utility file (e.g., in a src/utils directory) and imported into both controllers.
| acceptedHelpers: [ | ||
| { | ||
| helperId: { | ||
| type: mongoose.Schema.Types.ObjectId, | ||
| ref: 'Auth', | ||
| }, | ||
| serviceType: { | ||
| type: String, | ||
| }, | ||
| amount: { | ||
| type: Number, | ||
| min: 0, | ||
| }, | ||
| method: { | ||
| type: String, | ||
| enum: ['cash', 'upi', 'card'], | ||
| }, | ||
| paymentId: { | ||
| type: mongoose.Schema.Types.ObjectId, | ||
| ref: 'Payment', | ||
| }, | ||
| paymentStatus: { | ||
| type: String, | ||
| enum: ['pending', 'approved', 'verified', 'released', 'failed', 'free'], | ||
| default: 'free', | ||
| }, | ||
| acceptedAt: Date, | ||
| }, | ||
| ], |
There was a problem hiding this comment.
The schema introduces a new acceptedHelpers array. This seems to duplicate information that could be derived from the status field within the existing assignedHelpers array (e.g., when a helper's status is 'accepted').
Maintaining two separate lists for assigned and accepted helpers can lead to data inconsistency and complicates the logic for managing helper states. Consider relying solely on the status within the assignedHelpers array to determine which helpers have accepted the request. This would centralize state management.
| | **Helper** | ⚠️ Partial | Frontend config is wrong, but helperSlice uses correct `/api/helpers/v1/*`. | | ||
| | **Emergency** | ✅ Mostly Match | Core flows align; new features missing in frontend config. | | ||
| | **Medical** | ✅ Match | Frontend `medicalSlice` uses `/api/medical/v1/*` correctly. | | ||
| | **Notifications** | ❌ Missing | Frontend calls `/api/notifications/v1/*` but backend has no route registered. | |
There was a problem hiding this comment.
This report indicates that notification routes are missing in the backend. However, this same pull request adds the necessary notification routes in LifeLine-Backend/src/api/Notifications/v1/Notification.routes.mjs and registers them in server.mjs.
This discrepancy makes the documentation inconsistent with the codebase. Please update this document to reflect the latest changes to avoid confusion for future development and testing.
There was a problem hiding this comment.
Pull request overview
Adds a set of risk-assessment and testing/design documents for SOS upgrade + AI triage flows, alongside substantial frontend/backend implementation updates to support location stabilization, SOS orchestration, notifications, payments, and triage-to-existing-emergency binding.
Changes:
- Added multiple docs: SOS upgrade/triage Postman guides, HLD/LLD specs, and consolidated risk assessment/index docs.
- Frontend: implemented location stabilization, SOS runtime bootstrap/recovery, expanded API endpoint mappings, and updated multiple screens/slices to align with new flows.
- Backend: added Notifications + Payments routers/controllers/models, extended Emergency + Helper models/services, and updated triage handlers to bind/update existing emergencies.
Reviewed changes
Copilot reviewed 106 out of 109 changed files in this pull request and generated 8 comments.
Show a summary per file
| File | Description |
|---|---|
| docs/tests/sos-upgrade-postman-testing.md | Postman guide for SOS upgrade (payment/OTP/profile/stats). |
| docs/tests/sos-first-triage-postman-testing.md | Postman guide for SOS-first + AI triage enrichment flow. |
| docs/sos-upgrade-hld-lld.md | HLD/LLD spec for SOS upgrade roadmap (payments/OTP/profile/stats). |
| docs/risk-assessment-doc-mismatches.md | Doc mismatch tracking and appendix index. |
| docs/future-implementation-summary.md | Consolidated future work sequencing across subsystems. |
| docs/codebase-risk-assessment.md | Executive summary index for risk assessment reports. |
| docs/ai-triage-sos-hld-lld.md | HLD/LLD spec for AI triage → SOS integration and rules. |
| ai-logs/Frontend/frontend-location-accuracy-change-log-2026-03-10.md | Log describing frontend location accuracy changes. |
| ai-logs/Frontend/frontend-location-accuracy-change-log-2026-03-10-2026-03-10_17-54-21.md | Duplicate/detailed log copy incl. doc sync notes. |
| ai-logs/Backend/.gitkeep | Keeps backend ai-logs directory tracked. |
| Lifeline-Frontend/tsconfig.json | TS compiler settings adjustments (bundler resolution, libs). |
| Lifeline-Frontend/src/utils/filePicker.utils.ts | Image picker defaults (square crop, reduced quality). |
| Lifeline-Frontend/src/shared/utils/locationStabilizer.ts | New location filtering/smoothing + emit decision logic. |
| Lifeline-Frontend/src/shared/utils/error.utils.ts | Type cleanup for API error payload shape. |
| Lifeline-Frontend/src/shared/tasks/location.task.ts | Background location task stabilization + socket readiness + role support. |
| Lifeline-Frontend/src/shared/store/middleware/socketMiddleware.ts | Update socket service import style. |
| Lifeline-Frontend/src/shared/services/speech.service.ts | Lint suppression for require + simplified catch. |
| Lifeline-Frontend/src/shared/services/socket.service.ts | Adds role/userId to location update + triage emergencyId param + import style. |
| Lifeline-Frontend/src/shared/hooks/useSocket.ts | Socket hook import cleanup and unused selector removal. |
| Lifeline-Frontend/src/shared/hooks/useBackgroundLocation.ts | Background tracking options updated (highest accuracy, 5s intervals). |
| Lifeline-Frontend/src/features/emergency/services/triageApi.service.ts | Triage API supports emergencyId binding + typed emergencyData. |
| Lifeline-Frontend/src/features/emergency/hooks/useEmergency.ts | SOS-first triage flow: trigger SOS first, then start triage with emergencyId. |
| Lifeline-Frontend/src/features/emergency/emergencySlice.ts | Adds payment/OTP/profile thunks; enhances accept helper payload. |
| Lifeline-Frontend/src/features/auth/screens/WelcomeScreen.tsx | Removes unused theme destructuring. |
| Lifeline-Frontend/src/features/auth/screens/VerifySkillsScreen.tsx | Formatting cleanup; removes unused loading state. |
| Lifeline-Frontend/src/features/auth/screens/UserInfo.tsx | Better image metadata handling (mime type + filename normalization). |
| Lifeline-Frontend/src/features/auth/screens/UniversalMap.tsx | Removes unused Platform import. |
| Lifeline-Frontend/src/features/auth/screens/SecureLocationScreen.tsx | Reverse-geocode enrichment with multiple providers + race protection. |
| Lifeline-Frontend/src/features/auth/screens/MedicalInfoScreen.tsx | Removes unused imports/selectors and tightens variable usage. |
| Lifeline-Frontend/src/features/auth/screens/EmergencyContacts.tsx | Hook dependency fixes + const correctness. |
| Lifeline-Frontend/src/features/auth/medicalSlice.ts | Switches to named api import; formatting cleanup. |
| Lifeline-Frontend/src/features/auth/locationSlice.ts | Switches to named api import. |
| Lifeline-Frontend/src/features/auth/authSlice.ts | Switches to named api import; FormData header handling cleanup. |
| Lifeline-Frontend/src/features/User/Component/UserNav.tsx | Tailwind class ordering cleanup. |
| Lifeline-Frontend/src/features/SOS/sos.orchestrator.ts | New SOS activation orchestration + pending intent persistence. |
| Lifeline-Frontend/src/features/SOS/SOSRuntimeBootstrapper.tsx | New runtime bootstrapper for triggers (deeplink, native power button, recovery). |
| Lifeline-Frontend/src/features/Helper/helperSlice.ts | Align helper endpoints + adds helper stats thunk. |
| Lifeline-Frontend/src/features/Helper/Dashbard/v1/Components/StatusToggle.tsx | Persists helper role/availability for background tracking and awaits start/stop. |
| Lifeline-Frontend/src/features/Helper/Case/Components/SOSCard.tsx | UI refactor: richer priority styling and metadata display. |
| Lifeline-Frontend/src/core/Providers.tsx | Fixes imports and store typing usage. |
| Lifeline-Frontend/src/core/Navigation.tsx | Removes unused React import (component stub). |
| Lifeline-Frontend/src/config/socket.ts | Trims env socket URL for safer config parsing. |
| Lifeline-Frontend/src/config/api.ts | Named api export + expanded endpoint map (notifications, payments, emergency payment endpoints). |
| Lifeline-Frontend/src/ai/sarvam-stt.ts | Removes unused FileSystem import. |
| Lifeline-Frontend/app/_layout.tsx | Adds SOSRuntimeBootstrapper into app root. |
| Lifeline-Frontend/app/User/Profile/SavedAddressScreen.tsx | Uses Alert instead of unused error state; removes unused TextAreaField. |
| Lifeline-Frontend/app/User/Profile/AccountDetails.tsx | Removes unused local imports; delegates to feature component. |
| Lifeline-Frontend/app/User/Nearby.tsx | Uses named api import; minor formatting. |
| Lifeline-Frontend/app/User/IncomeUserSOS.tsx | UI refactor for incoming SOS list screen. |
| Lifeline-Frontend/app/User/Helper/HelperRequest.tsx | Removes commented-out socketService example block. |
| Lifeline-Frontend/app/User/Dashboard.tsx | Foreground/background location mode switching + stabilization + SOS hold time tweak. |
| Lifeline-Frontend/app/Helper/publicProfile[id].tsx | Removes unused router params/navigation hooks. |
| Lifeline-Frontend/app/Helper/_layout.tsx | Adds Case screen into stack and adjusts CaseDetails registration. |
| Lifeline-Frontend/app/Helper/SOSProfile.tsx | Placeholder SOS profile screen. |
| Lifeline-Frontend/app/Helper/Notifications.tsx | Notifications list UI refactor + fetch logic cleanup. |
| Lifeline-Frontend/app/Helper/EmergencyDetaill.tsx | Uses named api import; removes unused imports. |
| Lifeline-Frontend/app/Helper/Dashboard.tsx | Adds helper foreground location reporting when available. |
| Lifeline-Frontend/app/Helper/Case.tsx | New incoming SOS cases UI screen (static data). |
| Lifeline-Frontend/app/(main)/_layout.tsx | Removes unused react-native imports. |
| Lifeline-Frontend/app/(main)/SignUp.tsx | Formatting + safer coordinate parsing. |
| Lifeline-Frontend/app/(main)/Login.tsx | Effect deps updated to include router. |
| Lifeline-Frontend/app/(main)/Home.tsx | Removes test-only navigation helper and unused imports. |
| Lifeline-Frontend/app/(global)/SOSActiveAIScreen.tsx | Formatting cleanup and minor layout adjustments. |
| Lifeline-Frontend/app.json | Adds custom power-button plugin; formatting cleanup. |
| Lifeline-Frontend/Dockerfile | Adds container config for running Expo dev server. |
| LifeLine-Backend/src/utils/multer.utils.mjs | Allows HEIC/HEIF image uploads. |
| LifeLine-Backend/src/utils/cloudinary.utils.mjs | Adds Cloudinary upload/delete helper utility. |
| LifeLine-Backend/src/socket/handlers/triage.handler.mjs | Supports emergencyId binding + updates existing emergency from triage. |
| LifeLine-Backend/src/socket/SOCKET_API.md | Updates socket docs for location cadence/filtering + payload fields. |
| LifeLine-Backend/src/server.mjs | Serves /uploads statically; mounts notifications + payments routes. |
| LifeLine-Backend/src/config/mongo.config.mjs | Trims Mongo URI and forces IPv4 family option. |
| LifeLine-Backend/src/api/User/User.utils.mjs | Includes profileImage in user responses. |
| LifeLine-Backend/src/api/User/User.service.mjs | Accepts/updates profileImage fields. |
| LifeLine-Backend/src/api/Payment/Payment.utils.mjs | CRUD helpers for Payment model. |
| LifeLine-Backend/src/api/Payment/Payment.routes.mjs | Adds authenticated payments router (create/release). |
| LifeLine-Backend/src/api/Payment/Payment.model.mjs | Adds Payment schema. |
| LifeLine-Backend/src/api/Payment/Payment.controller.mjs | Adds Payment create/release endpoints. |
| LifeLine-Backend/src/api/Notifications/v1/Notification.routes.mjs | Adds authenticated notifications routes. |
| LifeLine-Backend/src/api/Notifications/v1/Notification.controller.mjs | Implements list/unread/read endpoints for notifications. |
| LifeLine-Backend/src/api/NGO/NGO.controller.mjs | Robust nearby query parsing + geoNear aggregation and meta. |
| LifeLine-Backend/src/api/Location/Location.controller.mjs | Robust nearby query parsing + meta in responses. |
| LifeLine-Backend/src/api/Helper/Helper.service.mjs | Computes earnings from Payment collection instead of mock values. |
| LifeLine-Backend/src/api/Helper/Helper.routes.mjs | Adds helper stats route. |
| LifeLine-Backend/src/api/Helper/Helper.model.mjs | Adds earnings/performance fields to helper schema. |
| LifeLine-Backend/src/api/Helper/Helper.controller.mjs | Adds helper stats controller method. |
| LifeLine-Backend/src/api/Emergency/Emergency.routes.mjs | Adds payment approve/verify + SOS profile endpoints. |
| LifeLine-Backend/src/api/Emergency/Emergency.model.mjs | Adds medicalInfo + payment fields + richer helper acceptance data. |
| LifeLine-Backend/src/api/Emergency/Emergency.controller.mjs | Accept helper includes service/amount/method; adds approve/verify/profile endpoints. |
| LifeLine-Backend/src/api/Auth/v1/Auth.service.mjs | Adds profile image public-id field handling. |
| LifeLine-Backend/src/api/Auth/v1/Auth.model.mjs | Adds profileImagePublicId field. |
| LifeLine-Backend/src/Ai/triage/triageState.mjs | Stores bound emergencyId in session state. |
| LifeLine-Backend/src/Ai/triage/triageService.mjs | Supports emergencyId binding and ownership validation via effective userId. |
| LifeLine-Backend/src/Ai/triage/triage.controller.mjs | Supports emergencyId binding and emergency update vs create. |
| LifeLine-Backend/docs/api-mismatch-report.md | Updates mismatch report contents (now partially stale vs current PR). |
| LifeLine-Backend/docs/20-End-to-End-Workflows.md | Formatting + updated location tracking behavior description. |
| LifeLine-Backend/docs/16-Backend-Features-Guide.md | Formatting + location tracking behavior updates. |
| LifeLine-Backend/docs/11-Socket-Protocol.md | Formatting + expanded location event/payload documentation. |
| LifeLine-Backend/docs/04-Business-Logic-and-Rules.md | Formatting + updated location tracking rule description. |
| LifeLine-Backend/docker-compose.yml | Adds mongo service + env + log rotation options. |
| LifeLine-Backend/.env.example | Adds Cloudinary config variables; formatting fix. |
| .gitignore | Adds Windows AppData ignores. |
Comments suppressed due to low confidence (1)
Lifeline-Frontend/src/shared/services/socket.service.ts:234
- Socket re-registration on reconnect calls
registerUser(this.state.userId)butSocketServiceStatedoes not track the user's role, so reconnects will typically re-register without a role. Since backend logic can depend onsocket.userRolefor location handling, consider persistingrolein service state and always emitting{ userId, role }once known.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # Codebase Risk Assessment (LifeLine) | ||
|
|
||
| Date: 2026-03-10 | ||
| Scope: Backend, Frontend, and Documentation | ||
| Method: Static review of code paths and configuration. No runtime tests executed. |
There was a problem hiding this comment.
PR description says "docs only", but this PR includes substantial runtime code changes (frontend + backend: sockets, location tracking, payment/notification routes, etc.). Please update the PR description/testing notes to reflect that this is not a docs-only change so reviewers apply the right level of scrutiny and CI expectations.
| setErrorMessage(null); | ||
| setLoading(true); | ||
| const response = await api.get(`/api/notifications/v1/user/${userId}`); | ||
| const data = response?.data?.data; | ||
| setNotifications(Array.isArray(data) ? data : []); |
There was a problem hiding this comment.
This screen fetches notifications from /api/notifications/v1/user/${userId}, but the backend notifications router exposes GET /api/notifications/v1 (scoped by the authenticated user) and does not define a /user/:id path. As written, this request will 404 in production; switch to API_ENDPOINTS.NOTIFICATIONS.LIST (or equivalent) and rely on auth for scoping.
| | **Helper** | ⚠️ Partial | Frontend config is wrong, but helperSlice uses correct `/api/helpers/v1/*`. | | ||
| | **Emergency** | ✅ Mostly Match | Core flows align; new features missing in frontend config. | | ||
| | **Medical** | ✅ Match | Frontend `medicalSlice` uses `/api/medical/v1/*` correctly. | | ||
| | **Notifications** | ❌ Missing | Frontend calls `/api/notifications/v1/*` but backend has no route registered. | |
There was a problem hiding this comment.
This doc still states that the backend does not register /api/notifications/v1/* routes, but src/server.mjs in this PR now mounts notificationRoutes at /api/notifications/v1. Please update this mismatch report accordingly (otherwise it will immediately be stale/misleading).
| | **Notifications** | ❌ Missing | Frontend calls `/api/notifications/v1/*` but backend has no route registered. | | |
| | **Notifications** | ✅ Match | Frontend and backend both use `/api/notifications/v1/*`. | |
| try { | ||
| const { emergencyId, helperId, userId, amount, method, serviceType } = | ||
| req.body; | ||
| const payment = await PaymentUtils.createPayment({ | ||
| emergencyId, | ||
| helperId, | ||
| userId, | ||
| amount, | ||
| method, | ||
| serviceType, | ||
| }); |
There was a problem hiding this comment.
createPayment trusts helperId and userId from the request body. This allows any authenticated caller to create payments on behalf of other users/helpers. Derive userId from req.user.userId and validate that (emergencyId, helperId) correspond to an actual assignment/acceptance before creating a payment record.
| const payment = await PaymentUtils.updatePaymentStatus( | ||
| paymentId, | ||
| 'released', | ||
| ); | ||
| res.status(200).json({ success: true, data: payment }); |
There was a problem hiding this comment.
releasePayment unconditionally marks any payment as released for any authenticated user, with no authorization (owner/assigned helper) and no state-transition validation (e.g., only after OTP verification). This is a critical escalation path. Enforce that the caller is allowed to release this payment (likely the emergency owner) and that the current status allows transition to released; return 404/403/409 accordingly when violated.
| const payment = await PaymentUtils.updatePaymentStatus( | |
| paymentId, | |
| 'released', | |
| ); | |
| res.status(200).json({ success: true, data: payment }); | |
| // Load the payment first to perform authorization and state checks | |
| const payment = await PaymentUtils.getPaymentById(paymentId); | |
| if (!payment) { | |
| return res | |
| .status(404) | |
| .json({ success: false, message: 'Payment not found' }); | |
| } | |
| // Determine caller identity from common auth properties | |
| const callerId = | |
| (req.user && req.user.id) || | |
| req.userId || | |
| (req.auth && (req.auth.id || req.auth.userId)); | |
| if (!callerId) { | |
| // Authenticated context is expected here; treat missing caller as forbidden | |
| return res | |
| .status(403) | |
| .json({ success: false, message: 'Forbidden' }); | |
| } | |
| // Only the emergency owner or assigned helper is allowed to release the payment | |
| if (payment.userId !== callerId && payment.helperId !== callerId) { | |
| return res | |
| .status(403) | |
| .json({ success: false, message: 'Forbidden' }); | |
| } | |
| // Enforce valid state transition to "released" | |
| if (payment.status !== 'otp_verified') { | |
| return res.status(409).json({ | |
| success: false, | |
| message: 'Invalid payment status for release', | |
| }); | |
| } | |
| const updatedPayment = await PaymentUtils.updatePaymentStatus( | |
| paymentId, | |
| 'released', | |
| ); | |
| res.status(200).json({ success: true, data: updatedPayment }); |
| useEffect(() => { | ||
| if (!userId || !isAvailable) return; | ||
|
|
||
| let isActive = true; | ||
| let timerId: ReturnType<typeof setInterval> | null = null; | ||
|
|
||
| const reportLocation = async () => { | ||
| try { | ||
| if (!isActive) return; | ||
| if (!socketService.isConnected()) { | ||
| socketService.connect(); | ||
| return; | ||
| } | ||
|
|
||
| socketService.registerUser(userId, "helper"); | ||
|
|
||
| const loc = await ExpoLocation.getCurrentPositionAsync({ | ||
| accuracy: ExpoLocation.Accuracy.Highest, | ||
| mayShowUserSettingsDialog: true, | ||
| }); | ||
|
|
||
| socketService.updateLocation({ | ||
| latitude: loc.coords.latitude, | ||
| longitude: loc.coords.longitude, | ||
| accuracy: loc.coords.accuracy || undefined, | ||
| altitude: loc.coords.altitude || undefined, | ||
| speed: loc.coords.speed || undefined, | ||
| heading: loc.coords.heading || undefined, | ||
| userId, | ||
| role: "helper", | ||
| timestamp: new Date().toISOString(), | ||
| }); | ||
| } catch (error) { | ||
| console.error("Helper foreground location report failed:", error); | ||
| } | ||
| }; | ||
|
|
||
| const bootstrap = async () => { | ||
| const { status } = await ExpoLocation.requestForegroundPermissionsAsync(); | ||
| if (status !== "granted") { | ||
| console.warn("Helper foreground location permission denied."); | ||
| return; | ||
| } | ||
|
|
||
| await reportLocation(); | ||
| timerId = setInterval(reportLocation, HELPER_LOCATION_UPDATE_INTERVAL_MS); | ||
| }; |
There was a problem hiding this comment.
This helper dashboard starts a foreground setInterval location reporter when isAvailable is true, but availability toggle also starts background tracking via useBackgroundLocation(). Without coordinating foreground vs background modes (like the user dashboard does with AppState), helpers may emit duplicate location updates and drain battery. Consider switching modes based on app state or disabling the background task while this foreground loop is active.
| ); | ||
| // /api/helpers/v1/checkCurrentAvailability/699ac6a6e6b3b33cff46e09b | ||
| router.post('/', AuthMiddleware.authenticate, HelperController.createHelper); | ||
| router.get('/stats/:id', HelperController.getHelperStats); |
There was a problem hiding this comment.
GET /stats/:id is added without AuthMiddleware.authenticate, unlike other sensitive helper endpoints. This exposes earnings/performance data publicly by helper ID. Add auth middleware here and enforce that only the helper (or an admin role) can access their stats.
| router.get('/stats/:id', HelperController.getHelperStats); | |
| router.get( | |
| '/stats/:id', | |
| AuthMiddleware.authenticate, | |
| HelperController.getHelperStats, | |
| ); |
| LOGIN: "/api/auth/v1/login", | ||
| REGISTER: "/api/auth/v1/create/user/auth", | ||
| CHECK_EMAIL: "/api/auth/v1/check-email", | ||
| VERIFY_EMAIL: "/api/auth/v1/verify-email", | ||
| CHECK_EMAIL: (email: string) => `/api/auth/v1/check-email/${email}`, | ||
| VERIFY_EMAIL: (token: string) => `/api/auth/v1/verify-email/${token}`, | ||
| FORGOT_PASSWORD: "/api/auth/v1/forgot-password", |
There was a problem hiding this comment.
CHECK_EMAIL and VERIFY_EMAIL embed user-provided values directly into the URL path. Emails/tokens can contain characters that must be URL-encoded (e.g., +, @, /). Encode these path segments (e.g., encodeURIComponent) at construction time to avoid broken requests.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 106 out of 109 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
Summary
Testing